In communication networks which support Session Initiation Protocol (SIP), user equipment devices (UEs) register with the network before they can place or receive calls. During registration a user device sends a registration request to a registration entity that registers the user device with the network.
SIP allows multiple registrations for the same address of record (AOR). This means that a user may operate and register multiple devices, e.g., such as a smartphone and a tablet device, using the same address of record (AOR). In simple terms an AOR is a like a username that is assigned to a SIP entity without regard to the device or devices that username might be used with. When a user sends a registration request from a device, the AOR corresponding to the user is specified in the TO header of the registration request. While a specified AOR corresponds to the user, the AOR does not specify the device or devices currently using that AOR. For example a user can use one single AOR to register multiple devices including, e.g., a smartphone, a SIP desk telephone, a PC, or a tablet device.
Since multiple devices may be using the same AOR and may be registered with the same AOR, when a service request, e.g., INVITE, is sent to the registrar, e.g., to establish a call, the registrar may be confused as to which of the devices registered with the same AOR the service request corresponds to. While information included in the contact header of the registration requests or INVITE signals allows a user to associate one or more devices to a single AOR by using a different IP address or port number for each device, from the perspective of the receiving device the use of IP address and/or port number to identify and/or correlate service request to registration instance is not a very reliable approach and may often prove not fruitful. FIGS. 2 and 3 discuss various deficiencies of some approaches for correlating a call to a corresponding registration instance when a plurality of devices register using the same address of record (AOR).
FIG. 2 is a drawing 200 illustrating an example that shows the problem that occurs in correlating a call to a corresponding registration instance when a plurality of devices are registered using the same address of record (AOR). FIG. 2 shows signaling between various devices during registration and later when a service request, e.g., INVITE, is sent to a registrar. For purposes of discussion consider that both UE device 262 (e.g., a smartphone) and UE device 264 (e.g., an iPAD) are being operated for using SIP services using the same single address of record, e.g., AOR-A. Thus the two devices first register with the same AOR. In this approach to correlate calls to correct registration instances illustrated in the example of FIG. 2, the session border controller SBC 266 uses a parameter in the contact header toward the registrar/AS 268 with different values for each registration instance for the same AOR. The value of this parameter allows registrar/AS 268 to distinguish between different registrations for different instances for the same AOR so that it can direct calls to the correct instance and apply services as needed. As discussed below this mechanism has shortcomings and prerequisites which makes it unreliable in a number of cases.
Consider the following discussion of the processing steps and signaling. In step 202 UE A 262 sends a registration request 203 including AOR-A as the address of record towards the registrar. The SBC 266 receives and processes the registration request 203 in step 204. In step 206 the SBC 266 includes a registration instance parameter “REG-INS” with a value “1” into the contact header of the registration request 203 to generate a registration request 203′ with the registration instance parameter. Next the SBC 266 forwards the registration request 203′ with the registration instance parameter “REG-INS=1” to the registrar 268. In this example the contact header of the registration request 203′ is CONTACT: AOR-A@SBC-IP:port; REG-INS=1. In step 208 the registrar 268 receives and processes the registration request 203′ to complete registration operations. In step 210 the SIP registrar 268 sends a signal 211 (e.g., 200 OK) to UE A 262 via the SBC 266 indicating that the registration is successful. The SBC 266 receives the 200 OK signal in step 212. In step 214 the SBC 266 forwards the 200 OK signal (as signal 211′) to the UE A which receives it in step 216.
Steps 218 through 232 illustrate processing steps and signaling relating to UE B 264 registration which uses the same AOR as UE A 262. In step 218 UE B 264 sends a registration request 219 including AOR-A as the address of record towards the registrar 268. The SBC 266 receives and processes the registration request 219 in step 220. In step 222 the SBC 266 includes a registration instance parameter “REG-INS” with a value “2” into the contact header of the registration request 219 to generate a registration request 219′ with the registration instance parameter. In this approach it is considered that the SBC 266 is aware that the two registration requests (203, 219) are from different devices using the same AOR and thus inserts different registration instance values in the registration requests. Further in step 222 the SBC 266 forwards the registration request 219′ with the registration instance parameter “REG-INS=2” to the registrar 268. In this example, the contact header of the registration request 219′ is CONTACT: AOR-A@SBC-IP:port; REG-INS=2. In step 224 the registrar 268 receives and processes the registration request 219′ to complete the registration. Since a different parameter value is specified in registration request 219′ than the registration instance of the existing registration 203′, the registrar 268 treats the new registration 219′ as a new registration attempt for AOR-A by a new instance. In step 226 the registrar 268 sends a signal 227 (e.g., 200 OK) to UE B 264 via the SBC 266 indicating that the registration is successful. The SBC 266 receives the 200 OK signal 227 in step 228. In step 230 the SBC 266 forwards the 200 OK signal (as signal 227′) to UE B 264 which receives it in step 232.
When UE B 264 attempts a service request, e.g., call request, the SBC 266 is able to determine which device the service request is coming from assuming that the connection, e.g., TCP connection, utilized for both the registration request and a later service request is the same. This is illustrated in steps 236 through 240. In step 236 UE B 264 sends an INVITE message 237 towards the registrar 268. In step 238 the SBC 266 receives the INVITE 237 and determines that the INVITE 237 is in the context of the existing registration for UE B 264 and correlates the registration request 219 based on the fact that the INVITE 237 corresponds to the same call flow and used the existing TCP connection used for registration request 219 for UE B 264. Since the SBC 266 is able to correlate INVITE 237 with the correct registration for UE B 264, in step 239 the SBC 266 inserts the registration instance value for the corresponding registration, i.e., “REG-INS=2”, into the contact header of the INVITE 237 to generate INVITE 237′. Further in step 239 the SBC 266 sends the INVITE 237′ to the registrar 268. In step 240 the registrar 268 receives and processes the INVITE 237′ and since the contact header includes the SBC inserted registration instance value “REG-INS=2” the registrar is able to correlate the INVITE 237 with the correct registration instance and accordingly is able to provide further signaling to the appropriate device, i.e., UE B 264.
While the above approach works in the scenario discussed above, one of the disadvantages of this approach is that it requires the SBC to know the instance from which the call is placed so that it can insert the registration instance parameter with different registration instance values for different registration instances in the registration requests being forwarded to the registrar thereby allowing the registrar to correlate the call with the correct registration instance. However in a number of situations it is difficult or impossible for the SBC to make such a determination. For example, in some cases the TCP connection used by a UE for a call (e.g., INVITE) is different than the one used for an earlier registration (e.g., for registration request). In some cases some devices use a new TCP connection for each call they place. In such a case the SBC may not be able to correlate the call coming over a new TCP connection with an earlier registration instance which was over a different TCP connection. In another scenario there is a SBC failover and a new active SBC instance loses its TCP connection information. When a device attempts to use the TCP connection established during registration to initiate a new call, it would detect it as down and establish a new TCP connection. Again the SBC will not be able to correlate the call over a new TCP connection with an earlier registration instance. Furthermore in cases where one or more network address translation (NAT) devices are used, with multiple instances behind the same NAT device, the source IP Address/port pair of an INVITE packet is not reliable for use in determining the correct instance placing the call. For example in some cases all REGISTER/INVITE requests from all instances behind the same NAT device use the same public IP Address and port information for INVITE/REGISTER. Thus in such cases relying on the contact header information, e.g., IP address and/or port number, to correlate a call to the correct instance is not effective. Thus it should be appreciated that this approach fails to serve the intended purpose in a number of cases and there is a need for improved methods and apparatus for correlating service request, e.g., calls, with registrations.
FIG. 3 is a signaling flow diagram 300 of an example showing the unreliability of an IP address/source port number matching approach used for call-registration instance correlation in cases where a plurality of devices are registered with the same address of record (AOR). In addition to the set of devices shown in FIG. 2, the example of FIG. 3 further involves the use of a NAT device 301 between the UE devices and the SBC 266. For purposes of discussion consider that both UE device 262 (e.g., a smartphone) and UE device 264 (e.g., an iPAD) are being operated for using SIP services using the same single address of record, e.g., AOR-A. Since the NAT device 301 is used, the signaling exchange between various devices passes through the NAT device which may, and in many cases does, shield the actual IP address/port number of the actual device sending the signal and insert an IP address/port number corresponding to the NAT device itself.
In step 302 UE A 262 sends TCP SYN signal 303 directed to the SBC 266 to establish a TCP connection. The NAT device 301 receives the TCP SYN signal 303 in step 304. In step 306 the NAT device 301 generates a TCP SYN signal 303′ to establish the TCP connection with the TCP SYN signal 303′ including a NAT device 301 assigned IP address, e.g., IP-1, and port number, e.g., port-1. In some situations the assigned IP address is the NAT device's IP address and port number that the NAT device 301 is using to forward signals from UE A 262 directed to other devices. This IP address (IP-1) and port number (port-1) is indicated as the IP address/port combination corresponding to the source device, e.g., UE A 262, in the signals from UE A 262 going via the NAT device 301. Further in step 306 the NAT device 301 sends the TCP SYN signal 303′ to the SBC 266. In step 308 the SBC 266 receives and processes the TCP SYN signal 303′. In some embodiments the IP address and port number used in the TCP SYN 303′ sent towards the SBC 266 is not the actual IP address/port pair used by UE A 262 but is seen by the SBC 266 as corresponding to the source address. Thus a device, e.g., SBC 266, that receives signal 303′ would perceive IP-1 and port number port-1 as corresponding to the UE A 262 and would perceive signals coming from IP address IP-1 and port number port-1 as coming from UE A 262. Arrow 309 indicates that the TCP connection is established between UE A 262 and the SBC 266. As part of the TCP connection establishment one or more additional signals such as SYN ACK and TCP ACK may be exchanged.
In step 310 UE A 262 sends a registration request 311, e.g., directed to a SIP registrar, over the established TCP connection. The NAT device 301 receives the registration request 311 in step 312. In step 314 the NAT device 301 generates a registration request 311′ by including the IP address (IP-1) and port number (port-1) in a header of registration request 311. Further in step 314 the NAT device 301 sends the registration request 311′ to the SBC 266 which receives the registration request 311′ in step 316 and in turn forwards the registration request to the SIP registrar. Upon successful registration, the registrar sends back a SIP 200 response 319 indicating successful registration to UE A via the SBC 266 and NAT device 301 which is finally received by the UE A as SIP 200 response 319′ in step 324. The SBC forwards (step 318) the SIP 200 response 319 to UE A which goes through the NAT device 301 (steps 320, 322).
Steps 326 through 348 illustrate similar signaling relating to establishing a TCP connection for registration of UE B 264. In step 326 UE B 264 sends TCP SYN signal 327 directed to the SBC 266 to establish a TCP connection. The NAT device 301 receives the TCP SYN signal 327 in step 328. In step 330 the NAT device 301 generates a TCP SYN signal 327′ to establish the TCP connection with the TCP SYN signal 327′ including a NAT device inserted IP address, e.g., IP-1, and port number, e.g., port-2. Further in step 330 the NAT device 301 sends the TCP SYN signal 327′ to the SBC 266. In step 332 the SBC 266 receives and processes the TCP SYN signal 327′. As part of the TCP connection establishment one or more additional signals such as SYN ACK and TCP ACK may be exchanged. Arrow 333 indicates that the TCP connection is established between UE B 264 and the SBC 266.
In step 334 UE B 264 sends a registration request 335, e.g., directed to the SIP registrar, over the established TCP connection for UE B 264. The NAT device 301 receives the registration request 334 in step 336. In step 338 the NAT device 301 generates a registration request 335′ by including the IP address (IP-1) and port number (port-2) in a header of registration request 335. Further in step 336 the NAT device 301 sends the registration request 335′ to the SBC 106 which receives the registration request 335′ in step 340 and in turn forwards the registration request to the SIP registrar. Upon successful registration, the registrar sends back a SIP 200 response indicating successful registration to UE B 264 via the SBC 266 (step 342) and NAT device 301 which is finally received by the UE B 264 in step 348. The SBC 266 forwards (step 342) the SIP 200 response 343 from the registrar to UE B 264 as signal 200 343′ which goes through the NAT device 301 (steps 344, 346) before reaching UE B 264 in step 348.
Now consider that UE A 262 wants to access a service, e.g., establish a call, and for this the UE initiates a new TCP connection rather than using the established TCP connection used for registration. This occurs in a number of cases where devices communicate using SIP. In fact some devices establish a new TCP connection for each call they place. In step 350 UE A 262 again initiates signaling exchange to establish a new TCP connection by sending a TCP SYN signal 351. The NAT device 301 receives the TCP SYN signal 351 in step 352. In step 354 the NAT device generates a TCP SYN signal 351′ to establish the TCP connection for UE B 264, by including a NAT device inserted IP address, e.g., IP-1, and port number, e.g., port-3. Further in step 354 the NAT device 301 sends the TCP SYN signal 351′ to the SBC 266 which receives it in step 356. Arrow 357 indicates that the new TCP connection is established between UE A 262 and the SBC 266.
In step 358 UE A 262 sends an INVITE signal 359, e.g., directed to the registrar/application server, over the new TCP connection. The NAT device 301 receives the INVITE 359 in step 360. In step 362 the NAT device generates a INVITE 359′ by including the IP address (IP-1) and port number (port-3) in a header of INVITE signal 359′. Note that while the NAT device used the same IP address (IP-1) for the INVITE 359′, the source port number for the INVITE 359 is different from the one used for registration of UE A 262 in step 314 which was port-2. Further in step 362 the NAT device sends the INVITE 359′ to the SBC 266 which receives the INVITE in step 364. From the perspective of SBC 266 which receives the INVITE signal 359′ and sees “Port-3” as the source port of the INVITE, this INVITE signal cannot be correlated to the registration instance for UE A 262 (and thus cannot be mapped back to UE A 262) since the source port used for registration is different than the source port used for the INVITE corresponding to UE A 262. From the above illustration it can be appreciated that correlating calls to registration instances using IP address/port number is not reliable and may not work in various scenarios.
Relying on SIP Contact header content is not reliable either as UEs registering for the same AoR may be behind different NAT devices and can be assigned the same private IP Address. Furthermore, sometimes the SIP Contact header is populated with a FQDN (fully qualified domain name) value, which is not really resolving to the actual IP Address currently owned by a UE device. The issues of NAT device restart and NAT devices with multiple public IP Addresses make mechanisms utilizing source IP Address for registration/call correlation problematic. Thus such approaches which utilize IP address/port number information indicated in signals and/or SIP Contact header content to determine and match the source instance, are not reliable.
From the above discussion it should be appreciated that there is a need for improved communications methods and apparatus for correlating calls to registration instances. The need is particularly great for such improved methods and apparatus for correlating calls to registration instances in cases where multiple devices are registered using the same address of record and/or when there are multiple instances using the same address of record.